Token authentication system and method

ABSTRACT

A method for calculating a One Time Password. A secret is concatenated with a count, where the secret is uniquely assigned to a token. The secret can be a private key or a shared secret symmetric key. The count is a number that increases monotonically at the token with the number of one-time Passwords generated at the token. The count is also tracked at an authentication server, where it increases monotonically with each calculation of a one-time Password at the authentication server. An OTP can be calculated by hashing a concatenated secret and count. The result can be truncated.

RELATED APPLICATIONS

This patent application is a Continuation of U.S. patent applicationSer. No. 10/590,415, filed Oct. 20, 2006, which is a nation stage entryapplication claiming priority under 35 U.S.C. §371 to Patent CooperationTreaty Application No. PCT/US05/05481, filed Feb. 23, 2005, which claimspriority to U.S. Provisional Application No. 60/546,194, filed Feb. 23,2004, each of which are herein incorporated by reference.

TECHNICAL FIELD

The field of the invention is authentication, and in particularauthentication using a hardware device.

SUMMARY

A method for calculating a One Time Password. A secret is concatenatedwith a count, where the secret is uniquely assigned to a token. Thesecret can be a private key or a shared secret symmetric key. The countis a number that increases monotonically at the token with the number ofOne Time Passwords generated at the token. The count is also tracked atan authentication server, where it increases monotonically with eachcalculation of a One Time Password at the authentication server. An OTPcan be calculated by hashing a concatenated secret and count. The resultcan be truncated.

BACKGROUND

A common step in deciding whether to grant a request for access to dataor services in a network is to identify and authenticate the requestinguser. Authentication includes the process of verifying the identity of auser. A known identification and authentication system includesassociating a user identifier (“user id”) and a secret (“password”) fora user. The password can be a secret shared between the user and anauthentication service. The user can submit his user id and password tothe authentication service, which compares them with a user id andassociated password that can be stored at the service. If they match,then the user is said to have been authenticated. If not, the user issaid not to be authenticated.

A token is a device that can be used to authenticate a user. It caninclude one or more secrets, some of which can be shared with avalidation center. For example, a token can store a secret key that canbe used as the basis for calculating a One Time Password (OTP). A OTPcan be a number (or alphanumeric string) that is generated once and thenis not reused. The token can generate an OTP and send it along with aunique token serial number to an authentication server. Theauthentication server can calculate an OTP using its copy of the secretkey for the token with the received serial number. If the OTPs match,then the user can be said to be authenticated. To further strengthen thelink from the user to the token, the user can establish a secretPersonal Identification Number (PIN) shared with the token that must beentered by the user to unlock the token. Alternatively, the PIN can beshared between the user, the token and the authentication server, andcan be used with other factors to generate the OTP. A token typicallyimplements tamper-resistant measures to protect the secrets fromunauthorized disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an authentication procedure in accordance with anembodiment of the present invention.

FIG. 2 shows an authentication procedure in accordance with anotherembodiment of the present invention.

DETAILED DESCRIPTION

An embodiment of the present invention includes a protocol forgenerating One Time Passwords (“OTPs”) at a hardware device that can beused to authenticate a user. The OTPs are generated by a token, whichcan be a physical device that includes mechanisms to prevent theunauthorized modification or disclosure of the software and informationthat it contains, and to help ensure its proper functioning.

An embodiment of this protocol can be sequence based, and can betwo-factor, e.g., based upon something the user knows (such as aPersonal Identification Number, a secret shared between the user and theauthentication service) and a physical device having special properties(e.g., a unique secret key such as a private key, or a shared secretsymmetric key) that the user possesses (e.g., a token.).

The protocol for generating the OTPs can be based upon a counter, e.g.,a monotonically increasing number based, for example, on the number oftimes a OTP has been requested from the token. The value of the OTP canbe displayed on a token, and can be easily read and entered by the user,e.g., via a keyboard coupled to a computer that is in turn coupled to anetwork. The OTP can be transportable over the RADIUS system.

An embodiment of the protocol in accordance with the present inventioncan based on an increasing counter value and a static symmetric keyknown only to the token and an authentication service (the “strong auth”service.) An OTP value can be created using the HMAC-SHA1 algorithm asdefined in RFC 2104, or any other suitable hash algorithm. This hashedMAC algorithm has the strength of SHA-1, but allows the addition of asecret during the calculation of the output.

The output of the HMAC-SHA1 calculation is 160 bits. However, this valuecan be truncated to a length that can be easily entered by a user. Thus,

OTP=Truncate(HMAC-SHA1 (Count, Secret))

Both the client and authentication server can calculate the OTP value.If the value received by the server matches the value calculated by theserver, then the user can be said to be authenticated. Once anauthentication occurs at the server, the server increments the countervalue by one.

Although the servers counter value can be incremented after a successfulOTP authentication, the counter on the token can be incremented everytime the button is pushed. Because of this, the counter values on theserver and on the token can often be out of synchronization. Indeed,there is a good chance that the token will always be out ofsynchronization with the server given the user environment (e.g., theuser pushes the button unnecessarily, button is pushed accidentally,user mistypes the OTP, etc.)

Because the server's counter will only increment when a valid OTP ispresented, the server's counter value on the token is expected to alwaysbe less than the counter value on token. It is important to ensure thatresynchronization is to ensure it's not a burden to either the user orthe enterprise IT department.

Synchronization of counters is in this scenario can be achieved byhaving the server calculate the next n OTP values and determine if thereis a match, where n is an integer. If we assume that the differencebetween the count at the token and the count at the server is 50, thendepending on the implementation of the strong auth server, the serverwould at most have to calculate the next 50 OTP values. Thus, forexample, if the correct OTP is found at the n+12 value, then the servercan authenticate the user and then increment the counter by 12.

It is important to carefully choose a value for n that can be easilycalculated by the server. There should be upper bounds to ensure theserver doesn't check OTP values forever, thereby succumbing to a Denialof Service attack.

Truncating the HMAC-SHA1 value to a 6 character value could make a bruteforce attack easy to mount, especially if only numeric digits are used.Because of this, such attacks can be detected and stopped at the strongauth server. Each time the server calculates an OTP that does notvalidate, it should record this and implement measures to prevent beingswamped, e.g., at some point, turn away future requests for validationfrom the same source. Alternatively, the user can be forced to wait fora longer period of time between validation attempts.

Once a user is locked out, the user can be to “self-unlock” by providinga web interface that would require the user, for example, to entermultiple OTP in a sequence, thus proving they have the token.

Once the shared secret has been combined with the counter, a 160 bit(20-byte) HMAC-SHA1 result can be obtained. In one embodiment, at mostfour bytes of this information for our OTP. The HMAC RFC (RFC 2104—HMAC:Keyed-Hashing for Message Authentication) further warns that we shoulduse at least half the HMAC result in Section 5, Truncated Output:

-   -   Applications of HMAC can choose to truncate the output of HMAC        by outputting the t leftmost bits of the HMAC computation . . .        . We recommend that the output length t be not less than half        the length of the hash output . . . and not less than 80 bits (a        suitable lower bound on the number of bits that need to be        predicted by an attacker).

Thus, another way is needed to choose only four or fewer bytes of theHMAC result in a way that will not weaken either HMAC or SHA1. In one,dynamic offset truncation, described below, can be used.

Dynamic Offset Truncation.

The purpose of this technique is to extract a four byte dynamic binarycode from an HMAC-SHA1 result while still keeping most of thecryptographic strength of the MAC.

-   -   1. Take the last byte (byte 19)    -   2. Mask off the low order four bits as the offset value    -   3. use the offset value to index into the bytes of the HMAC-SHA1        result.    -   4. return the following four bytes as the dynamic binary code.

The following code example describes the extraction of a dynamic binarycode given that hmac_result is a byte array with the HMAC-SHA1 result:

int offset=hmac_result[19] & 0xf;

int bin_code=(hmac_result[offset] & 0x7f)<<24

|(hmac_result[offset+1] & 0xff)<<16

|(hmac_result[offset+2] & 0xff)<<8

|(hmac_result[offset+3] & 0xff);

The following is an example of using this technique:

We treat the dynamic binary code as a 31 bit, unsigned, big-endianinteger; the first byte is masked with a 0x7f.

The One Time Password for a given secret and moving factor can varybased on three parameters: Encoding Base, Code Digits, and Has Checksum.With 10 as an Encoding Base, 7 Code Digits and Has Checksum set to TRUE,we continue with the above example:

-   -   The hex value 0x50ef7f19 converts to 1357872921 base 10.    -   The last 7 digits are 7872921    -   The credit card checksum of the code digits calculates 7 as the        checksum.

10−((5+8+5+2+9+2+2)mod 10)=10−(33 mod 10)=10−3=7

-   -   Yielding the following OTP: 78729217

The following is the Glossary of terms used in this application:

-   -   Checksum Digit—Result of applying the Credit-Card checksum        algorithm to the Code Digits. This digit is optional. This check        should catch any single transposition or any single character        mistyped.    -   Code Digits—This parameter indicates is the number of digits to        be obtained from the binary code. We calculate the Code Digits        by converting the Binary Code to the Encoding Base, zero padding        to be at least Code Digits, and taking the right hand (low        order) digits. With ten as an Encoding Base, no more than nine        Code Digits can be supported by the 31-bit Binary Code.    -   Credit Card checksum algorithm—This checksum algorithm has the        advantage that it will catch any single mistyped digit, or any        single adjacent transposition of two digits. These are the most        common types of user errors.    -   Encoding Base—This parameter indicates what base to use for the        password. Base 10 is the preferred base because it can be        entered in a numeric pad.    -   Has Checksum Digit—This boolean parameter indicates if a        checksum digit should be added to create the OTP. If there is no        checksum digit, just the Code Digits are used as the OTP. If        there is a checksum digit, it is calculated using the Code        Digits as input to the Credit-Card checksum algorithm.    -   OTP—The One-Time-Password. This value is constructed by        appending the Checksum Digit, if any, to the right of the Code        Digits. If there is no Checksum Digit, the OTP is the same as        the Code Digits.

The One Time Number value is calculated by first shifting in the HashBits, and then the Synchronization Bits, and then shifting in the resultof the check_function ( ) of the prior intermediate value.

The binary value is then translated to appropriate character values.There are three likely character representations of the password:Decimal, Hexadecimal, and Alpha-Numeric.

Decimal Hexadecimal Alpha-Numeric Required Display Type 7-Segment7-Segment Alpha-Numeric Conversion Cost Moderate Trivial Simple Bits percharacter 3.2 4 5 Keyboard Entry Simple Easy Easy Cell Phone Entry EasyDifficult Difficult

Decimal.

The token can convert the dynamic binary code to decimal and thendisplay then last Code Digits plus optionally the checksum. For example,for a six digit, no checksum, decimal token will convert the binary codeto decimal and display the last six digits.

Hexadecimal.

The token can convert the dynamic binary code to hexadecimal and thendisplay then last Code Digits plus optionally the checksum. For example,for a six digit, no checksum, hexadecimal token will convert the binarycode to hexadecimal and display the last six digits.

Alphanumeric.

The token can convert the dynamic binary code to base 32 and thendisplay then last Code Digits plus optionally the checksum. For example,for a six digit, no checksum, base 32 token will convert the binary codeto base 32 and display the last six digits.

The PIN.

In order to be a true two-factor authentication token, there can also bea “what you know” value in addition to the “what you have” value of theOTP. This value is usually a static PIN or password known only to theuser. This section discusses three alternative architectures to validatethis static PIN in accordance with the present invention.

PIN Validation in the Cloud.

Enabling PIN validation in the cloud can bind a single PIN to a singletoken. The PIN should be protected over the wire to ensure it is notrevealed. PIN management (set, change) should be implemented by thestrong auth service.

PIN Validation at the Enterprise.

Enabling PIN validation in the cloud may mean multiple PIN's for asingle token.

The PIN need never leave the “security world” of the enterprise. PINmanagement can be implemented by the enterprise.

PIN Validation at the Token.

This embodiment can be implemented using a keypad on the token. The PINis never sent over the wire, and may be used as a seed to the OTPalgorithm. The PIN may be used to simply unlock the token.

Example Data Flows.

This section describes two data flow scenarios. The first scenarioassumes that the StrongAuth service does not knows the usernameassociated with a token. In this scenario it is assumed that the PINmanagement operations require the user to enter their token SN, insteadof their user name.

The second scenario is very similar to the first, except by the factthat the user name is the key into the StrongAuth service, instead ofthe token SN. There are a few issues in this case. First, the usernameis known to the service, and second we must come up with a scheme toensure a unique mapping from a username to a token SN.

FIG. 1 shows an authentication procedure in accordance with anembodiment of the present invention. It assumes the following:

-   -   Token SN and S distributed to StrongAuth Service;    -   Customer account associated with each token;    -   PIN associated with a particular token;    -   StrongAuth service saves only the SHA-1 hash of the PIN in the        DB;    -   Token SN added as an attribute to the user account at the        Enterprise, the plugin maps the username to the SN.

A strong authentication server 110, an enterprise authentication server120 and a client 130 are coupled, e.g., through a network (not shown.)As shown in FIG. 1, a user at the client sends a request for access to aprotected resource to enterprise server 120. The server determines ifaccess to the resource requires authentication. If so, it sends an“authentication required” message to the client 130. The user can beprompted for a username and a password. The user can push the button onhis token (not shown) to obtain a OTP. The OTP can be generated asdescribed above, e.g., by hashing a combination of the token secret andthe present value for the count as it is stored at the token. The userthen enters his username and his Personal Identification Number (PIN)concatenated to the OTP provided by the token. This information is sentto the enterprise server 120. The enterprise server 120 looks up thetoken serial number based on the username, and sends the serial numberand the PIN+OTP to the authentication server 110. The authenticationserver 110 looks up a record based upon the serial number to obtainlocal hashed values of the PIN and the secret and purported count. Thiscan be done because the token secret can be shared between the token towhich it is uniquely assigned and the authentication server 110. Theauthentication server then calculates an OTP based upon the secret forthe token and the current value of the count for that token stored atthe authentication server. If the calculated OTP matches the receivedOTP, then the value of the count at the authentication server 110 isincremented by one. Otherwise, the authentication server can try againto calculate the OTP by incrementing the count for the token and hashingit with the secret for the token. This can be done because, as describedabove, the count value at the authentication server 110 may be differentthan the count value at the token (not shown.) This procedure can berepeated any number of times within reason to enable the count value to“catch up” with the count value at the token. In an embodiment, thenumber of such repeated tries to authenticate a token at theauthentication server is terminated after a predetermined number of thesame, e.g., 12. In the event that the token cannot be successfullyauthenticated by the authentication server 110, the authenticationserver sends an “not authenticated” message to the enterprise server120. If the token is successfully authenticated, then the authenticationserver sends an “authenticated” message to the enterprise server 120.Based upon the result obtained from the authentication server 110, theenterprise server denies or grants, respectively, the requestedpermission from the client to access a resource.

FIG. 2 shows an authentication procedure in accordance with anotherembodiment of the present invention. It assumes the following:

-   -   Token SN and S distributed to StrongAuth Service;    -   Customer account and username is associated with each, token;    -   PIN associated with a particular token;    -   StrongAuth service saves only the SHA-1 hash of the PIN in the        DB;    -   Username is forwarded from enterprise to the Strong Auth        service.

The authentication procedure of FIG. 2 is the same as for FIG. 1 untiljust after the username and PIN+OTP is sent from the client 130 to theenterprise server 120. Rather than look up the token serial number basedupon the username, the enterprise server 120 forwards the authenticationrequest (including the username and PIN+OTP) to the authenticationserver 110. The authentication server looks up a record based upon theusername, can verify the PIN, and then follow the same procedure asshown in FIG. 1 for the rest of the process.

1. (canceled)
 2. A token comprising: a counter to generate a count,wherein the count is a value that increases with each One Time Passwordgenerated by the token; a storage to store a secret and the count; and acomponent, coupled to the storage, to: concatenate the secret with thecount; calculate a hash based upon the concatenated secret and count;and truncate a result of the hash to obtain a new One Time Password. 3.The token of claim 2, further comprising: a button, wherein the new OneTime Password is to be generated and the count is to be incremented inresponse to a press of the button; and a display to display the new OneTime Password.
 4. The token of claim 2, wherein the hash is calculatedusing an SHA-1 hash function and the secret is a symmetric cryptographickey.
 5. The token of claim 2, wherein the One Time Password comprises atmost 4 bytes from the hash.
 6. The token of claim 2, wherein truncatingthe result of the hash comprises: determining an offset value from fourbits of a predetermined byte of the hash; indexing into bytes of thehash based on the offset value; and returning values for a predeterminednumber of bytes of the hash that are identified based on the indexing.7. An authentication server comprising: a storage to store a secret anda count that are associated with a token, wherein the count is a valuethat increases with each received valid One Time Password; and acomponent, coupled to the storage, to: concatenate the secret with thecount; calculate a hash based upon the concatenated secret and count;and truncate a result of the hash to compute a One Time Password.
 8. Theauthentication server of claim 7, wherein the computed One Time Passwordis to be generated in response to receipt of a request comprising areceived One Time Password, and wherein the component is further to:compare the computed One Time Password with the received One TimePassword; and responsive to a determination that the computed One TimePassword matches the received One Time Password, authenticate therequest and increment the count.
 9. The authentication server of claim8, wherein responsive to a determination that the computed One TimePassword fails to match the received One Time Password, the component isfurther to perform authentication operations comprising: incrementingthe count; computing a new One Time Password based on the incrementedcount; comparing the new One Time Password with the received One TimePassword; and if the new One Time Password matches the received One TimePassword, authenticating the request and increment the count.
 10. Theauthentication server of claim 9, wherein: the component is further torepeat the authentication operations up to a threshold number of timesif the new One Time Password fails to match the received One TimePassword; and the component is to determine that the request is notauthenticated if no computed One Time Password matches the received OneTime Password.
 11. The authentication server of claim 7, wherein the OneTime Password comprises at most 4 bytes from the hash.
 12. Theauthentication server of claim 7, wherein truncating the result of thehash comprises: determining an offset value from four bits of apredetermined byte of the hash; indexing into bytes of the hash based onthe offset value; and returning values for a predetermined number ofbytes of the hash that are identified based on the indexing.
 13. Amethod comprising: receiving, by an authentication server, a request forauthentication, the request comprising a first One Time Passwordgenerated by a token, wherein the first One Time Password is based upona value of a first count at the token and a secret shared between thetoken and the authentication server; calculating, by the authenticationserver, a second One Time Password based upon the secret and a firstvalue of a second count at the authentication server; comparing thecalculated second One Time Password with the received first One TimePassword; responsive to a determination that the calculated second OneTime Password corresponds to the received first One Time Password,determining that the request is authenticated; and responsive to adetermination that the calculated second One Time Password does notcorrespond to the received first One Time Password, performingadditional authentication operations by the authentication server, theadditional authentication operations comprising: incrementing the secondcount to a next value; recalculating the second One Time Password basedupon the incremented second count and the secret; and comparing therecalculated second One Time Password with the received first One TimePassword.
 14. The method of claim 13, further comprising: responsive toa determination that the recalculated second One Time Passwordcorresponds to the received first One Time Password, determining thatthe request is authenticated; and responsive to a determination that therecalculated second One Time Password does not correspond to thereceived first One Time Password, repeating the additionalauthentication operations by the authentication server until at leastone of a) the count has been incremented a threshold number of times orb) the recalculated second One Time Password corresponds to the receivedfirst One Time Password.
 15. The method of claim 14, further comprising:resetting the count to the first value after the count is incrementedthe threshold number of times if the recalculated second One TimePassword does not correspond to the received first One Time Password.16. The method of claim 13, wherein the request further comprises aserial number that is uniquely associated with the token and a personalidentification number associated with a user, the method furthercomprising: retrieving the second count and the secret based on at leastone of the serial number or the personal identification number.
 17. Themethod of claim 13, wherein the hash function is SHA-1 and the secret isa symmetric cryptographic key.
 18. The method of claim 13, whereincalculating the second One Time Password comprises: concatenating thesecret with the second count; calculating a hash based upon theconcatenated secret and the second count; and truncating a result of thehash to obtain the second One Time Password.
 19. The method of claim 18,wherein the second One Time Password comprises at most 4 bytes from thehash.
 20. The method of claim 18, wherein truncating the result of thehash comprises: determining an offset value from four bits of apredetermined byte of the hash; indexing into bytes of the hash based onthe offset value; and returning values for a predetermined number ofbytes of the hash that are identified based on the indexing.
 21. Anauthentication server comprising: a storage to store a shared secret anda second count that are associated with a token, wherein the secondcount is a value that increases with each received valid One TimePassword; and a component, coupled to the storage, to: receive a requestfor authentication, the request comprising a first One Time Passwordgenerated by the token, wherein the first One Time Password is basedupon a value of a first count at the token and the shared secret;calculate a second One Time Password based upon the shared secret and afirst value of the second count; compare the calculated second One TimePassword with the received first One Time Password; responsive to adetermination that the calculated second One Time Password correspondsto the received first One Time Password, determine that the request isauthenticated; and responsive to a determination that the calculatedsecond One Time Password does not correspond to the received first OneTime Password, perform additional authentication operations by theauthentication server, the additional authentication operationscomprising: incrementing the second count to a next value; recalculatingthe second One Time Password based upon the incremented second count andthe secret; and comparing the recalculated second One Time Password withthe received first One Time Password.
 22. The authentication server ofclaim 21, wherein the component is further to: responsive to adetermination that the recalculated second One Time Password correspondsto the received first One Time Password, determine that the request isauthenticated; and responsive to a determination that the recalculatedsecond One Time Password does not correspond to the received first OneTime Password, repeat the additional authentication operations until atleast one of a) the count has been incremented a threshold number oftimes or b) the recalculated second One Time Password corresponds to thereceived first One Time Password.
 23. The authentication server of claim21, wherein the component is further to: reset the count to the firstvalue after the count is incremented the threshold number of times ifthe recalculated second One Time Password does not correspond to thereceived first One Time Password.